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ABSTRACT 

The  aeronautical  transport  protocol  AeroTP  addresses  the  challenges  of  end-to-end  communication  in 
highly  dynamic  airborne  telemetry  network  environment.  The  protocol  has  multiple  modes:  reliable,  near¬ 
reliable,  quasi-reliable,  unreliable  connection,  and  unreliable  datagram.  We  present  our  Python  implemen¬ 
tation  of  reliability  modes  that  provide  end-to-end  error  control.  The  results  of  preliminary  experiments 
conducted  on  Linux  systems  using  AeroTP  quasi-reliable  mode  are  comparable  to  simulation  results. 

I.  INTRODUCTION  AND  MOTIVATION 

Airborne  telemetry  networks  poses  many  challenges  to  end-to-end  communication  across  the  network. 
Traditional  transport  and  network  protocols  do  not  perform  well  in  this  environment  [  1  ] .  A  domain-specific 
solution  Airborne  Network  Telemetry  Protocol  (ANTP)  suite  was  designed  to  optimize  performance  in 
this  tactical  environment  [2].  This  also  aims  to  provide  edge-to-edge  compatibility  with  legacy  TCP/IP- 
based  Internet  architecture.  The  protocol  suite  consists  of  AeroTP  -  a  TCP-friendly  transport  protocol  [3] 
with  multiple  QoS  (quality  of  service)  modes  for  the  TmNS  (telemetry  network  system),  AeroNP  -  an 
IP-compatible  network  protocol  (addressing  and  forwarding),  and  AeroRP  -  a  routing  protocol  [4]  which 
exploits  location  information  to  mitigate  the  short  contact  durations  of  high-velocity  airborne  nodes.  The 
protocol  suite  is  designed  to  perform  well  in  an  environment  in  which  rapidly-changing  topology  prevents 
global  routing  convergence,  as  well  as  those  in  which  persistent  stable  end-to-end  paths  do  not  exist.  The 
protocols  have  been  verified  using  the  ns-3  simulator  and  analysis  has  shown  significant  performance 
improvement  compared  to  traditional  transport  protocols  [5].  Having  verified  these  protocols,  the  next 
step  towards  deployment  of  the  ANTP  suite  is  developing  a  cross-platform  implementation  of  protocols. 
A  preliminary  work  on  the  software  architecture  and  implementation  of  the  ANTP  suite  in  Python  was 
presented  previously  [6]. 

This  paper  presents  the  implementation  architecture  of  AeroTP  (aeronautical  transport  protocol)  with 
emphasis  on  the  reliability  modes  providing  end-to-end  error  control.  Closed-loop  retransmission  is  pro¬ 
vided  by  the  ARQ  (automatic  repeat  request)  mechanism  in  reliable  and  near-reliable  modes.  Reliable 
mode  preserves  end-to-end  acknowledgment  semantics  from  source  to  destination  as  the  only  way  to  guar¬ 
antee  delivery.  Near-reliable  mode  is  highly  reliable,  but  does  not  guarantee  delivery  since  the  gateway  [7] 
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uses  split  ARQ  and  immediately  returns  TCP  ACKs  to  the  source  [3].  An  open-loop  error  recovery  is 
achieved  using  FEC  (forward  error  correction)  mechanism  in  quasi-reliable  mode.  We  also  present  pre¬ 
liminary  analysis  of  quasi-reliable  mode  in  an  emulated  environment.  AeroTP  provides  two  additional 
modes  that  do  not  provide  any  reliability:  unreliable  connection  and  unreliable  datagram.  Unreliable  con¬ 
nection  mode  does  not  use  any  error  correction  mechanism  at  the  transport  layer  and  relies  exclusively  on 
FEC  of  the  link  layer  if  available.  Unreliable  datagram  mode  is  intended  to  pass  UDP  traffic  transparently 
to  maintain  edge-to-edge  compatibility.  In  this  paper,  we  only  consider  operational  modes  providing  error 
control  that  are  applicable  to  the  telemetry  network. 

The  rest  of  the  paper  is  organized  as  follows:  Section  II  introduces  the  background  on  AeroTP  with 
previously  conducted  tests  using  simulation  techniques  and  related  work.  Section  III  presents  the  Python 
implementation  of  the  AeroTP  protocol  focusing  on  the  ARQ  and  FEC  based  reliability  modes.  In  Sec¬ 
tion  IV,  performance  analysis  of  quasi-reliable  mode  using  FEC  is  presented.  Section  V  concludes  and 
gives  future  directions  for  this  work. 

II.  BACKGROUND  AND  RELATED  WORK 

AeroTP  is  a  TCP-friendly  domain- specific  transport  protocol  designed  to  meet  the  needs  of  the  air¬ 
borne  network  environment:  dynamic  resource  sharing,  QoS  support  for  fairness  and  precedence,  real¬ 
time  data  service,  and  bidirectional  communication  [2,  3].  AeroTP  has  several  operational  modes  that 
support  different  service  classes:  reliable,  nearly-reliable,  quasi-reliable,  unreliable  connection,  and  unre¬ 
liable  datagram.  The  first  of  these  is  fully  TCP  compatible,  the  last  fully  UDP  compatible,  and  the  others 
TCP-friendly  with  reliability  semantics  matching  the  needs  of  the  mission  and  capabilities  of  the  network. 
AeroTP  uses  opportunistic  connection  establishment  as  an  alternative  to  three-way  handshake  used  by 
TCP. 

AeroTP  has  been  designed  and  evaluated  previously  using  the  ns-3  simulator  [8,  5].  In  a  lossy  net¬ 
work  environment,  AeroTP  reliable-mode  performs  significantly  better  compared  to  traditional  TCP.  With 
higher  BER  (bit  error  rate),  end-to-end  delay  in  TCP  increases  by  orders  of  magnitude  whereas  AeroTP 
has  less  than  an  order  of  magnitude  increase.  AeroTP  quasi-reliable  mode  has  much  less  loss  due  to  the 
FEC  recovery  mechanism  compared  to  UDP  as  it  drops  packets  with  increasing  error  rates.  Furthermore, 
AeroTP  reliable  mode  has  less  overhead  compared  to  TCP,  while  quasi-reliable  mode  does  not  cause 
increased  delay  but  has  significant  overhead. 

Many  designs  and  implementations  of  network  and  transport  protocols  have  been  carried  out.  A  trans¬ 
port  layer  protocol  which  relies  on  end-to-end  mechanisms  to  detect  network  state  was  implemented  on 
Linux  kernel  and  results  were  also  verified  with  simulations  [9].  The  significant  impact  of  wireless  multi¬ 
hop  channel  on  TCP  throughput  and  loss  gives  insights  why  TCP  cannot  be  used  in  wireless  networks  [10]. 
A  survey  of  many  real-world  experiments  conducted  in  ad-hoc  networks  with  emphasis  on  MANET  (mo¬ 
bile  ad-hoc  network)  routing  protocols  is  presented  [11].  Our  work  is  different  as  AeroTP  is  a  domain- 
specific  transport  protocol  designed  for  end-to-end  communication  in  airborne  telemetry  networks.  The 
implementation  of  the  AeroRP  routing  protocol  and  AeroNP  network  protocol  upon  which  AeroTP  is 
designed  to  run  is  presented  in  our  companion  paper  [12]. 
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III.  IMPLEMENTATION  OF  AEROTP 


The  development  and  testing  of  AeroTP  is  carried  out  in  the  high-level  scripting  language  Python. 
It  provides  a  number  of  data  structures  and  libraries,  in  particular,  networking  libraries  such  as  sockets, 
packing  binary  data,  and  CRC  (cyclic  redundancy  check).  Python-based  implementations  require  less 
programming  time  leading  to  fast  prototyping  of  applications  [13]. 

AeroTP  is  designed  as  a  centralized  top-level  controller  module  that  guides  the  flow  setup,  termination, 
and  data  transfer  as  shown  in  Figure  1,  and  employs  supplemental  modules  designed  for  specific  services. 
The  controller  runs  independently  on  a  POSIX  operating  system  environment  as  a  daemon  on  both  source 
and  destination  nodes  to  provide  services  to  the  application  layer  for  end-to-end  communication.  The 
current  implementation  uses  UDP  sockets  for  compatibility  with  the  security  restrictions  in  PlanetLab 
testbed  [14]  systems,  which  is  one  of  the  emulation  environments. 


Figure  1 :  AeroTP  implementation  architecture 

The  controller  flow  at  the  source  begins  with  connection  setup  that  uses  the  state  machine  in  connection- 
oriented  modes.  During  the  connection  establishment,  the  overhead  of  a  three-way  handshake  is  eliminated 
by  an  opportunistic  connection  approach  that  overlaps  data  with  control.  Segmentation  is  followed  with 
optional  FEC  error-correcting  codes  added  to  the  payload.  Header  processing  involves  the  application 
layer  QoS  and  error  control  requirements  embedded  into  the  AeroTP_Header  object.  Depending  on 
the  class  of  service  used  by  the  application,  error  controlling  mechanisms  are  employed  in  the  subsequent 
steps.  These  functions  are  complimented  appropriately  at  the  destination  by  decomposing  the  segment 
based  on  service  mode,  maintaining  state,  and  aggregating  ACKs  followed  by  the  connection  teardown. 
In  addition  to  these  modules,  a  consistent  and  efficient  buffer-handling  mechanism  augments  the  main 
controller  using  sender  and  receiver  buffers. 

A.  End-to-end  Reliability  with  ARQ  mechanism 

AeroTP  reliable  and  near-reliable  mode  use  ARQ  mechanisms  to  provide  full  reliability  within  the 
TmNS  [8].  MACK  (multiple  ACK)  is  used  as  the  acknowledgement  mechanism.  It  dynamically  aggregates 
a  number  of  ACKs  hinging  upon  the  transmission  rate  and  loss  rate.  The  source  and  destination  use  control 
messages  (ASYN,  ASYNACK,  AFIN,  AFINACK)  for  connection  establishment  and  termination  as  shown 
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in  Figure  2.  The  source  initiates  an  end-to-end  connection  by  sending  the  ASYN  AeroTP.Header  object 
with  the  SYN  flag  set.  A  piggyback  flag  is  set  to  provide  options  to  use  traditional  three-way  handshake 
or  opportunistic  connection  establishment.  Once  the  ASYN  is  received  from  the  source,  the  connection 
state  is  set  to  ESTABLISHED  at  the  destination  and  the  sequence  number  of  the  ASYN  is  recorded  in 
a  MACK  control  message  to  be  sent  back  to  the  source.  The  first  acknowledged  sequence  number  is 
inserted  in  the  MACK  header  and  the  following  acknowledged  sequence  numbers  are  appended  as  the 
payload.  The  structure  of  a  MACK  control  message  is  shown  in  Figure  3  where  n  and  m  are  the  first  and 
last  acknowledged  TPDU  sequence  numbers,  respectively. 


Figure  2:  ARQ  connection  management 


Seq  n 

n+2 

n+ 4 

n+2m 

k _ _  „ _ 

V 
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_ _  „ _ J 

"V" 

MACK  Payload 


Figure  3:  MACK  header  and  payload 

After  the  source  sends  out  the  ASYN,  it  moves  to  the  ESTABLISHED  state  immediately.  The  source 
appends  TPDUs  (transport  protocol  data  units)  to  the  transmission  buffer  and  sends  them  to  the  destination 
in  the  FIFO  (first  in,  first  out)  order.  The  AeroTP  protocol  employs  a  selective-repeat  ARQ  mechanism  to 
provide  a  reliable  edge-to-edge  connection.  Whenever  the  source  sends  out  a  TPDU,  the  sequence  number 
and  TPDU  are  stored  in  an  additional  buffer  used  for  possible  retransmission,  implemented  by  using  a 
hash  table  (diet  ( )  data  structure  in  Python)  with  sequence  number  as  the  keys.  Figure  4  is  an  example 
showing  the  retransmission  procedure.  By  checking  the  next  MACK  from  the  destination,  the  source  will 
remove  the  sequence  number  with  its  counterpart  TPDU  sequence  numbers  (2,  6,  8,  10,  and  12)  in  the 
retransmission  buffer  and  append  the  unacknowledged  TPDUs  (sequence  number  4)  to  sender  buffer. 

After  the  transmission  buffer  is  empty,  the  source  will  send  out  an  AFIN  immediately  to  signal  the  end 
of  current  connection.  However,  it  is  possible  that  some  of  the  last  sent  several  TPDUs  are  lost  during 
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Figure  4:  AeroTP  ARQ  retransmission  mechanism 


the  transmission.  Therefore,  an  alternative  retransmission  mechanism  is  exploited.  When  the  last  MACK 
arrives  at  the  source,  if  all  the  sequence  numbers  of  last  set  of  TPDUs  are  acknowledged,  the  source  will 
just  wait  for  AFINACK  to  cease  the  connection;  if  some  sequence  numbers  are  missed,  it  triggers  a  time¬ 
out  mechanism  for  the  retransmission  of  the  last  set  of  TPDUs.  In  this  case,  the  destination  will  send  an 
ACK  back  to  the  source  immediately  for  each  single  TPDU  so  that  each  TPDU  is  acknowledged  individu¬ 
ally.  A  time-out  thread  is  employed  for  each  TPDU  by  using  the  Python  class  threading .  Timer,  and 
when  the  timer  expires  it  will  trigger  automatic  retransmission  of  that  TPDU.  When  AFINACK  reaches 
the  source  and  no  TPDUs  are  in  the  retransmission  hash  table,  the  source  moves  to  the  CLOSED  state 
and  the  destination  moves  to  the  LISTEN  state.  A  state  management  module  described  next,  is  used  for 
effective  event  transitions. 

The  state  management  module  is  a  FSM  (finite  state  machine)  based  module  [15]  that  effectively  man¬ 
ages  the  state  transitions  in  the  case  of  AeroTP  connection-oriented  modes.  The  state  transition  diagram 
is  shown  in  Figure  5.  The  module  maintains  AeroTP  states  and  possible  event  transitions  with  action  han¬ 
dlers.  A  set  of  tuples  each  representing  event  transitions  (input_symbol,  current-state,  action, 
next  _state)  with  optional  input  .symbol  are  initialized  that  vary  depending  on  the  AeroTP  re¬ 
liability  mode.  Then,  based  on  an  event  occurrence,  the  state  transitions  from  current-state  to 
new-state  and  takes  corresponding  action.  The  events  are  listed  in  Table  1. 

B.  Quasi- Reliability  with  FEC  mechanism 

Due  to  the  inherent  behavior  of  bit-errors  resulting  from  noise  and  interference  in  wireless  links  with 
dynamic  mobility,  relying  alone  on  retransmissions  to  efficiently  provide  reliable  data  transfer  is  not  suf¬ 
ficient.  An  open-loop  error  recovery  mechanism  such  as  FEC  achieves  an  arbitrary  level  of  statistical 
reliability.  This  also  means  it  does  not  guarantee  absolute  delivery  of  data,  while  eliminating  the  need 
of  ACKs  and  ARQ  completely.  We  use  the  RS  (Reed-Solomon)  class  of  error  correcting  codes  that  are 
predominantly  used  in  applications  such  as  RAID-like  systems,  optical  disk  storage  devices,  and  optical 
communication  technologies.  Quasi-reliable  mode  also  manages  a  subset  of  the  state  transitions  discussed 
earlier. 

RS  error  correcting  codes  are  linear  block  codes  that  can  detect  and  correct  multiple  burst  of  errors. 
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Figure  5 :  AeroTP  state  machine 


They  represents  data  as  polynomials  and  oversamples  them.  An  (n,  k)  code  encodes  k  source  data  bytes 
into  n  codewords,  with  the  ability  to  correct  at  most  (n  —  k)/ 2  errors.  We  use  publicly  available  RS  error 
correcting  Python  library  [16]  for  FEC  mechanism. 

A  widely  used  RS  code  uses  8-bit  symbols  as  it  facilitates  byte-oriented  systems  and  is  computationally 
less  intensive.  This  corresponds  to  the  number  of  symbols  in  the  encoded  block  to  be  n  =  28  —  1  =  255. 
To  provide  different  error  correcting  capabilities,  k  can  be  varied.  To  account  for  a  higher  payload  size  in 
the  TPDU,  a  mechanism  to  iteratively  encode  and  decode  codewords  is  incorporated. 


•  During  encoding  at  source,  chunks  of  codewords  are  computed  with  specified  FEC  strength  with 
default  n  being  255.  Two  conditions  are  possible:  the  sum  of  the  lengths  of  codewords  computed 
exceeds  the  length  of  the  maximum  payload  size,  or  the  length  of  the  codewords  is  less  than  the 
block  size  of  255.  In  the  former,  n  is  calculated  based  on  the  strength  whereas  k  is  computed  for 
blocks  of  smaller  size  in  the  latter. 

•  During  decoding  at  the  destination,  each  chunk  of  the  payload  is  decoded  individually  which  in¬ 
volves  computation  of  k.  To  simulate  different  noise  levels  in  the  network  during  analysis  stage,  a 
user-specified  BER  based  RateBasedErrModel  is  developed.  This  introduces  burst  errors  into 
the  payload  calculated  using  its  length  and  BER. 

An  object  of  RS  based  error  correcting  class  is  created  using  a  constructor  with  n  and  k  arguments 
computed  as  discussed  previously.  FEC  adds  redundancy  for  error  correcting  capability  that  overcomes 
the  necessity  of  retransmissions. 

C.  Supplemental  modules 

While  the  centralized  controller  provides  the  main  functionality,  supplemental  modules  serve  as  utili¬ 
ties  to  simplify  operations  and  provide  reusable  modules  across  different  AeroTP  modes.  These  modules 
make  use  of  the  object-oriented  features  of  Python.  They  act  as  independent  libraries,  instantiated  by  the 
centralized  controller. 
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Table  1 :  State  transition  definitions 


State 

Description 

CLOSED 

State  in  which  no  connection  exists  and  no  data  is  transferred 

LISTEN 

State  in  which  a  destination  is  ready  to  listen  to  any  incoming  data 

ASYN.SENT 

ASYN  message  sent  by  the  host  initiating  connection 

ESTABLISHED 

Steady  state  in  which  data  transfer  takes  place 

AFIN  SENT 

AFIN  message  sent  to  indicate  no  new  data  being  sent 

AFIN  RECEIVED 

AFIN  message  received  and  AFINACK  is  sent  as  an  acknowledgement 

APP.CONN 

Request  issued  by  the  application  to  initiate  connection  by  sending  ASYN 

APPJJSTEN 

Request  issued  to  the  receiving  host  to  move  to  the  LISTEN  state 

APP.CLOSE 

Request  to  initiate  closing  a  connection  by  sending  AFIN 

ASYN.RX 

ASYN  received,  indicating  a  connection  has  been  requested 

ASYNACK.RX 

ASYNACK  received,  indicating  connection  request  has  been  granted 

MACK  RX 

Single  or  multiple  packet  ACK  received 

AFIN  RX 

AFIN  received,  indicating  end  of  any  new  data,  initiating  connection  close 

CLOSE.TO 

A  timeout  allowing  outstanding  retransmissions  before  going  to  CLOSED  state 

LISTEN.TO 

A  timeout  to  go  to  LISTEN  state  so  that  the  destination  can  receive  all  data  packets 

Segmentation  and  header  processing  modules  are  a  prerequisite  for  processing  related  to  size  and 
alignment  of  control  and  payload  data  during  network  communication.  The  segmentation  module  accepts 
application  data  and  segments  into  chunks  for  transmission.  In  contrast,  the  destination  side  decapsulates 
the  segment  from  receiver  buffer  RECVJ3UFF.  Segmentation  also  provides  the  sequence  numbering  mech¬ 
anism,  which  numbers  each  TPDU  to  permit  resequencing.  Header  processing  at  the  source  helps  in  con¬ 
structing  the  header  in  network  byte  order  using  the  binary  packing  library  method  struct  .pack  (format, 
vl ,  v2 ,  .  .  . ) ,  which  can  easily  be  decomposed  at  the  destination.  The  arguments  vl ,  v2 ,  .  .  repre¬ 

senting  header  fields  are  packed  according  to  format.  This  module  provides  extensive  support  in  terms 
of  handling  header  field  attributes. 

Various  other  modules  serve  as  tools  to  validate  and  analyze  the  overall  implementation.  A  utility 
module  converts  values  between  different  numerical  base  formats  and  provides  time  related  functions 
using  the  date  time  library.  A  traffic  generator  module  generates  CBR  (constant  bit  rate)  application 
traffic  at  specified  rate,  which  helps  in  end-to-end  application  layer  protocol  behavior.  The  CRC  protects 
the  integrity  of  data  end-to-end  across  the  network.  It  can  be  used  in  conjunction  with  FEC  to  detect  errors. 

The  HEC  (header  error  check)  is  a  16-byte  strong  CRC  whereas  the  payload  has  a  32-byte  CRC  performed 
by  the  Python  library  module  binascii. 

IV.  PERFORMANCE  ANALYSIS 

Functionality  testing  of  all  AeroTP  modes  is  initially  conducted  on  the  PlanetLab  testbed  [17].  In  this 
section,  we  analyze  the  performance  of  AeroTP  quasi-reliable  mode  in  a  lossy  environment.  In  order  to 
test  the  accuracy  of  the  FEC  mechanism,  we  have  simplified  the  testing  on  two  systems  operating  with 
Debian  Linux  distribution.  1  MB  application  data  is  transmitted  from  one  of  the  systems  to  another  during 
a  single  scenario.  RS  codes  providing  FEC  strengths  from  zero  FEC  32  bit  words  to  250  FEC  words,  are 


7 


tested.  We  measure  the  cumulative  goodput  and  overhead  of  using  different  FEC  strengths  that  provides 
statistical  reliability.  Emulation  of  errors  with  varying  rates  is  done  at  the  destination  end. 


Figure  6:  Cumulative  goodput 


Figure  7:  Cumulative  goodput 


FEC  strength  [words/pkt] 


Figure  8:  Cumulative  overhead  Figure  9:  Cumulative  overhead 

Figure  6  shows  the  amount  of  data  correctly  delivered  as  BER  increases  with  varying  FEC  strength. 
At  the  strengths  tested,  except  for  high  strengths  (185.5  words  and  above),  the  total  amount  of  correctly 
delivered  data  decreases  as  the  error  rate  increases.  The  AeroTP  quasi-reliable  mode  eliminates  the  need 
for  ACKs  and  retransmissions  in  the  case  of  lossy  links  that  cause  bit  errors  at  the  cost  of  not  guaranteeing 
reliability.  Due  to  increased  noise  and  interference  in  the  wireless  channel,  more  bit  errors  reduce  the 
amount  of  correctly  delivered  data.  This  can  be  compensated  by  error  correction  with  sufficient  FEC 
strength.  Figure  7  shows  the  amount  of  data  correctly  delivered  for  different  FEC  strength  with  lower 
error  rates.  Each  FEC  strength  has  a  threshold  BER  that  can  deliver  entire  data  correctly.  An  FEC  strength 
of  85  words  is  able  to  correct  errors  occurring  at  rate  <  5.0  x  10~5. 

The  next  set  of  plots  indicate  the  overhead  added  by  the  FEC  mechanism.  Figure  8  shows  that  as  the 
FEC  strength  is  increased,  the  overhead  added  by  the  RS  codes  increases  (note  the  log  ?/-axis  scale).  This 
means  more  packets  are  required  to  carry  the  application  data.  The  reliability  induced  in  quasi-reliable 
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mode  comes  at  the  cost  of  additional  FEC  codewords  added  to  the  packet,  reducing  the  application  data 
in  each  packet.  Note  that  error  rate  does  not  affect  the  overhead  for  a  given  strength.  Figure  9  shows  the 
increase  in  the  overhead  with  increased  FEC  strength  quantifying  FEC  strength  with  respect  to  the  number 
of  packets  sent.  The  results  are  comparable  to  the  simulation  results  [5].  Significant  overhead  is  added 
that  can  influence  the  FEC  strength  value  to  be  used  in  AeroTP.  The  strength  value  can  be  adapted  based 
on  the  error-rates,  by  cross-layering  link  characteristics  with  link  and  MAC  (media  access  control)  layer. 

V.  CONCLUSIONS  AND  FUTURE  WORK 

The  implementation  of  AeroTP  protocol  extends  the  previous  work  of  simulation  to  real-world  sys¬ 
tems.  The  performance  analysis  of  quasi-reliable  mode  that  is  based  on  an  open-loop  error  recovery 
mechanism  shows  comparable  results  to  simulation  results.  Cross-layer  optimizations  can  be  considered 
in  order  to  effectively  use  quasi-reliable  mode,  given  the  overhead  of  FEC.  Future  work  includes  deploy¬ 
ment  and  performance  analysis  of  ANTP  suite  on  mobile  devices  in  a  mobile  ad-hoc  network  environment. 
Also,  a  hybrid  protocol  that  uses  ARQ  mechanism  as  an  extension  to  FEC  mechanism  [18]  in  the  case  of 
loss  of  packets  and/or  high  error  rates  is  being  considered. 
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